home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 3: Developer Tools / Linux Cubed Series 3 - Developer Tools.iso / devel / ver_cont / aegis.002 < prev    next >
Encoding:
Text File  |  1996-11-16  |  13.5 KB  |  389 lines
  1. Subject: Aegis Frequently Asked Questions (FAQ)
  2. From: Peter Miller <pmiller@agso.gov.au>
  3. Newsgroups: comp.software-eng,comp.software.config-mgmt,comp.software.testing,comp.sources.d,alt.sources.d
  4.  
  5. Submitted-by: Peter Miller <pmiller@agso.gov.au>
  6. Archive-name: aegis.2.3/FAQ
  7.  
  8. This  message  contains  answers to a number of frequently asked ques-
  9. tions about Aegis.  If you don't know what Aegis is, read on.
  10.  
  11. Suggestions for additions or improvements to this FAQ  are  most  wel-
  12. come.
  13.  
  14.                    Contents
  15. 1.   What is Aegis?
  16. 1.1.   What operating systems are supported?
  17. 1.2.   Where can I get Aegis?
  18. 1.3.   Is Aegis actively being maintained?
  19. 1.4.   Is there an Aegis mailing list?
  20. 1.5.   How does Aegis compare with program X?
  21. 2.   Configuration and initial build problems
  22. 2.1.   Changing Makefile and common/congig.h
  23. 2.2.   RCS
  24. 2.3.   SCCS
  25. 3.   Testing
  26. 3.1.   Can I use something besides a shell script?
  27. 3.2.   Testing curses programs
  28. 3.3.   Testing X11 programs
  29. 3.3.1.   replayXt
  30. 3.4.   Testing embedded systems
  31. 4.   Miscellaneous
  32. 4.1.   How do you pronounce ``Aegis''?
  33. 4.2.   How do I automate the integration queue?
  34. 4.3.   How do I enforce coding standards?
  35. 4.4.   How do I get dates printed before and after build commands?
  36. 4.5.   How do I stop Aegis automatically merging?
  37. 4.6.   Do I have to type all the config examples in the User Guide?
  38. 4.7.   Is there a way to recreate a previous baseline?
  39.  
  40. ----------------------------------------------------------------------
  41.  
  42. Subject: 1.  What is Aegis?
  43.  
  44. Aegis is a transaction-based software configuration management system.
  45. It  provides a framework within which a team of developers may work on
  46. many changes to a program independently, and Aegis  coordinates  inte-
  47. grating these changes back into the master source of the program, with
  48. as little disruption as possible.
  49.  
  50. For a more complete description, see  the  README  file  or  the  User
  51. Guide.  Both are available from the anonymous FTP site (see below).
  52.  
  53. ------------------------------
  54.  
  55. Subject: 1.1.  What operating systems are supported?
  56.  
  57. Aegis  will  run on almost any version of UNIX.  The distribution con-
  58. tains a configure script generate by GNU autoconf  to  adapt  to  your
  59. site.
  60.  
  61. There  is no Aegis port to OS/2, MS-DOS or VMS.  The author has no ex-
  62. pertise is these operating systems.  If you do  have  such  expertise,
  63. you  are  welcome to donate a port of Aegis, and I will try to include
  64. your work in the next release.
  65.  
  66. ------------------------------
  67.  
  68. Subject: 1.2.  Where can I get Aegis?
  69.  
  70. Aegis is available by anonymous FTP from
  71.        Host:   ftp.nau.edu
  72.        Dir:    /pub/Aegis
  73.        File:   aegis.2.3.README
  74.        File:   aegis.2.3.tar.gz   # the complete source
  75.        File:   aegis.2.3.ps.gz    # the User Guide
  76.        File:   aegis.2.3.faq      # this FAQ list
  77.  
  78. ------------------------------
  79.  
  80. Subject: 1.3.  Is Aegis actively being maintained?
  81.  
  82. Yes, Aegis is actively being maintained by the author.  You  can  con-
  83. tact him by email
  84.           Peter Miller <pmiller@agso.gov.au>
  85.  
  86. ------------------------------
  87.  
  88. Subject: 1.4.  Is there an Aegis mailing list?
  89.  
  90. Yes.   Discussion  may  include, but is not limited to: bugs, enhance-
  91. ments, and applications.  The list is not moderated.
  92.  
  93. The address of the mailing list is
  94.     aegis-users@agso.gov.au
  95.  
  96. DO NOT send email to the list if you wish to subscribe.
  97.  
  98. To subscribe to this mailing list, send an email message  to  majordo-
  99. mo@agso.gov.au with a message body containing the single line
  100.     subscribe aegis-users
  101. Please  note  that  agso.gov.au is an Internet site, so if you have an
  102. address which is not readily derived from your mail headers (majordomo
  103. is  only  a Perl program, after all) you will need to use a message of
  104. the form:
  105.     subscribe aegis-users address
  106. where address is an email address which makes sense from  an  Internet
  107. site.
  108.  
  109. The software which handles this mailing list CANNOT send you a copy of
  110. Aegis.  Please use FTP or ftp-by-email, instead.
  111.  
  112. ------------------------------
  113.  
  114. Subject: 1.5.  How does Aegis compare with program X?
  115.  
  116. For all X, ``The author has no experience with X.  If you wish to con-
  117. tribute  a  comparison  between Aegis and X, it will be considered for
  118. addition here.''
  119.  
  120. ------------------------------
  121.  
  122. Subject: 2.  Configuration and initial build problems
  123.  
  124. Aegis is accompanied by a set of regression tests,  and  the  BUILDING
  125. instructions  included  in  the  distribution  detail how to run these
  126. tests.
  127.  
  128. ------------------------------
  129.  
  130. Subject: 2.1.  Changing Makefile and common/congig.h
  131.  
  132. It is a Bad Idea to change the Makefile or the common/config  file  by
  133. hand.   This  is because much of the work done by the configure script
  134. in inter-related.
  135.  
  136. In particular, if you change the C compiler (CC) you  absolutely  must
  137. do this with the involvement of the configure script.
  138.  
  139. ------------------------------
  140.  
  141. Subject: 2.2.  RCS
  142.  
  143. The tests distributed with Aegis use RCS as their history tool.  It is
  144. important that you use version 5.6 or later.
  145.  
  146. There seems to be a problem with the version of RCS  distributed  with
  147. HP/UX,  even though it claims to be RCS-5.6.0.1.  You will need to get
  148. the latest GNU RCS if you are on a HP box.
  149.  
  150. ------------------------------
  151.  
  152. Subject: 2.3.  SCCS
  153.  
  154. The tests do not automatically detect that you have  SCCS.   You  will
  155. need to go out and grab RCS even if you already have SCCS installed at
  156. your site.
  157.  
  158. ------------------------------
  159.  
  160. Subject: 3.  Testing
  161.  
  162. One of the things many sites like about Aegis,  is  that  it  provides
  163. mandatory  testing.   This  enforcement of testing is optional, and is
  164. configurable pre-project.
  165.  
  166. Please note that even if Aegis' testing framework  is  not  useful  to
  167. your project, the other aspects of Aegis' process still are (e.g. con-
  168. current development, mandatory reviews, etc.).
  169.  
  170. ------------------------------
  171.  
  172. Subject: 3.1.  Can I use something besides a shell script?
  173.  
  174. Yes, the ``test_command'' field of the project config file may be  set
  175. to whatever command you like, see aepconf(5) for more information.
  176.  
  177. A shell script is the default, because you can run anything out of the
  178. shell script.  In particular, you can set  up  a  temporary  directory
  179. within  which to run the tests.  If you ``cd'' into this temporary di-
  180. rectory when running tests, cleanup, no matter what the fallout,  even
  181. a  core  dump,  is thus a simple matter of ``rm -rf'' of the temporary
  182. directory.
  183.  
  184. ------------------------------
  185.  
  186. Subject: 3.2.  Testing curses programs
  187.  
  188. I don't have a curses program tester, nor do I know of one.  It  seems
  189. to me that the ``screen'' program contains all the necessary elements,
  190. however additional code would be required to make it a  suitable  test
  191. harness.
  192.  
  193. If  anyone  has found suitable curses testers, even commercial ones, I
  194. would be happy to list (FTP) locations here.
  195.  
  196. ------------------------------
  197.  
  198. Subject: 3.3.  Testing X11 programs
  199.  
  200. I don't have an X11 program tester, however  several  commercial  ones
  201. seem to be advertised heavily.
  202.  
  203. If  anyone  has  found  suitable  X11 testers, even commercial ones, I
  204. would be happy to list additional (FTP) locations here.
  205.  
  206. ------------------------------
  207.  
  208. Subject: 3.3.1.  replayXt
  209.  
  210. ReplayXt is a library that allows Intrinsics (or Xt) based application
  211. to  be executed from a script file.  In particular, applications based
  212. on the Athena and the Motif toolkits can be played.  The author is Jan
  213. Newmarch <jan@pandonia.canberra.edu.au>
  214.  
  215. replayXt is available by anonymous FTP from
  216.              Host:   ftp.x.org
  217.              Dir:    /contrib/devel_tools
  218.              File:   replayXt.README
  219.              File:   replayXt.1.1.tar.z
  220.  
  221. The  author  has  not  personally used this system, and so can make no
  222. comment  on  it.   This  entry  originated  from  Simon  Pickup   <si-
  223. mon@adacel.com.au>
  224.  
  225. ------------------------------
  226.  
  227. Subject: 3.4.  Testing embedded systems
  228.  
  229. Yes,  embedded system can be developed with Aegis, Naturally, you will
  230. need a suitable cross compiler.
  231.  
  232. To test embedded software, you will need suitable testing hardware:
  233.  
  234. 1. you will need to be able to (automatically) download  the  software
  235. into  suitable  hardware  - probably with RAM emulating the ROM of the
  236. distributed product.
  237.  
  238. 2. you will need to be able to simulate the various inputs and capture
  239. the various outputs, if you don't want to do manual testing.
  240.  
  241. 3.  you  will  probably have to write the testing program yourself, to
  242. allow scripting the inputs and outputs.
  243.  
  244. 4. The gotcha is that in diverting input and output, you will need  to
  245. manually  test the device drivers, because the tests will probably not
  246. exercise them.
  247.  
  248. The author has worked in an environment like this, and Aegis is  defi-
  249. nitely intended to be useful in this situation.
  250.  
  251. ------------------------------
  252.  
  253. Subject: 4.  Miscellaneous
  254.  
  255. This  section contains a whole bunch of things which do not yet belong
  256. anywhere else.
  257.  
  258. ------------------------------
  259.  
  260. Subject: 4.1.  How do you pronounce ``Aegis''?
  261.  
  262. There are many alternatives for pronouncing this word, and  all  focus
  263. on  the  myriad  of sounds available for the "ae" vowel.  Alternatives
  264. include: maestro, aerial, encyclopaedia, etc.  The author  has  chosen
  265. the  pronunciation  found  in  the  majority of dictionaries: ee.j.iz.
  266. That is "ee" as in "tree", a "j" as in "job", and "iz" as in  "prism".
  267.  
  268. ------------------------------
  269.  
  270. Subject: 4.2.  How do I automate the integration queue?
  271.  
  272. There  is  a  shell  script  in  the  aegis library directory (usually
  273. /usr/local/lib/aegis/integrate_q.sh) which can  be  run  from  cron(1)
  274. daily,  or  whatever.   This shell script is a good starting point for
  275. customising automatic integrations.
  276.  
  277. Please note that the integration phase also serves to answer the ques-
  278. tion  ``who reviews the reviewers?''  Monitoring review quality is es-
  279. sential to maintain product quality.
  280.  
  281. ------------------------------
  282.  
  283. Subject: 4.3.  How do I enforce coding standards?
  284.  
  285. The ``diff_command'' field of the project config file  need  not  only
  286. difference the file, it can also be overloaded to do other things.  If
  287. the difference command files for any source file, the change  may  not
  288. leave the being developed state.
  289.  
  290. For  example,  if you wanted to check that line lengths were always 80
  291. characters or less, you could run the hypothetical  ``cklinlen''  com-
  292. mand at diff time, using
  293.     diff_command = "cklinlen $in && fcomp -w -s $orig $in -o $out";
  294. Checking other coding standards are also possible using the same basic
  295. method.
  296.  
  297. ------------------------------
  298.  
  299. Subject: 4.4.  How do I get dates printed before and after build  com-
  300.     mands?
  301.  
  302. Just  as  the  diff_command file of the project config file can be ex-
  303. tended, so can the build_command field.
  304.     build_command = "set +e; date; cook ...; x=$?; date; exit $x";
  305. You need to be careful about the -e flag, because  Aegis  invokes  the
  306. shell to run the commands with the -e option, to abort after the first
  307. error.
  308.  
  309. ------------------------------
  310.  
  311. Subject: 4.5.  How do I stop Aegis automatically merging?
  312.  
  313. The merging behaviour is controlled by the  ``diff_preference''  field
  314. of  the user config file.  See aeuconf(5) for more information.  There
  315. are also three command line options to the aed(1)  command  which  can
  316. override the preferences, see aed(1) for more information.
  317.  
  318. To stop the automatic merging, add the line
  319.     diff_preference = no_merge;
  320. to  the .aegisrc file in your more directory.  To specifically perform
  321. a merge after that, you will need to use the ``aed -merge_only''  com-
  322. mand.
  323.  
  324. ------------------------------
  325.  
  326. Subject:  4.6.   Do I have to type all the config examples in the User
  327.     Guide?
  328.  
  329. No, you do not.  The lib/config.example directory contains a number of
  330. files with the config command from the User  Guide ready for inserying
  331. into your project config file.
  332.  
  333. ------------------------------
  334.  
  335. Subject: 4.7.  Is there a way to recreate a previous baseline?
  336.  
  337. For example, let's say we have shipped one version to a  customer  and
  338. since  then  made 30 changes to the baseline.  When the customer calls
  339. in with a failure report that we can't reproduce, how can I easily re-
  340. build the baseline from 30 changes ago to help track down the error?
  341.  
  342. Yes,  it  is  possible  to reacreate a previous baseline.  You need to
  343. follow these steps:
  344.  
  345. 1. Determine which delta was shipped to the customer.  This is easiest
  346. if  you  embed  the version supplied by Aegis into your executables at
  347. build time.
  348.  
  349. 2. Create a change a change (you want to fix  the  bug,  right?)   and
  350. start developing it.
  351.  
  352. 3. Copy all of the project files into the change, using the delta num-
  353. ber determined in step 1.  Use these commands:
  354.     aecd
  355.     aecp . -delta N
  356. where N is the delta number from the first step.  Files created  since
  357. the  delta  will  be  copied into you chage as empty files, leave them
  358. alone for a while.
  359.  
  360. Note that you need Aegis 2.3 for directory copying to work  correctly.
  361. Eariler versions will need to use
  362.     aecd
  363.     aecp `aegis -list project_files -terse` -delta N
  364. Note the backward quotes.  The above can be abbreviated, its just long
  365. so you can see what it is doing.
  366.  
  367. 4. Build the change as normal.  This will completely rebuild the  ver-
  368. sion  sent  to  the customer.  Note that a number of things are beyonf
  369. Aegis' scope, like operating  system  updates  and  compiler  updates.
  370. These  can  have  an effect in accurately reproducing what was sent to
  371. the customer.
  372.  
  373. 5. Find the bug and fix it, as you would normally do.
  374.  
  375. 5. Merge the change.  This will bring the files up to the most  recent
  376. version, and merge the bug fix with the current version.
  377.  
  378. 6. You can no uncopy all of the files which are unchanged.  Aegis pro-
  379. vides a fast way to do this
  380.     aecpu -unchanged
  381. This command behaves like aecpu, but it goes hunting for  files  which
  382. are the same between the baseline and the development directory.  Note
  383. that you must do this step after the merge.
  384.  
  385. ------------------------------
  386.  
  387. End of aegis.2.3.faq Digest
  388. ***************************
  389.